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As humans venture farther from Earth for longer durations, it will become essential for 
those on the journey to have significant control over the scheduling of their own activities as 
well as the activities of their companion systems and robots. However, the crew will not do 
all the scheduling; timelines will be the result of collaboration with ground personnel. 
Emerging technologies such as in-space message buses, delay-tolerant networks, and in- 
space internet will be the carriers on which the collaboration rides. Advances in scheduling 
technology, in the areas of task modeling, scheduling engines, and user interfaces will allow 
the crew to become virtual scheduling experts. New concepts of operations for producing the 
timeline will allow the crew and the ground support to collaborate while providing 
safeguards to ensure that the mission will be effectively accomplished without endangering 
the systems or personnel. 


I. Introduction 

F OR all past and current human space missions, the final scheduling of tasks to be done in space has been devoid 
of crew control, flexibility, and insight. Ground controllers, with minimal input from the crew, schedule the 
tasks and uplink the timeline to the crew or uplink the command sequences to the hardware. Prior to the 
International Space Station (ISS), the crew could make requests about tomorrow’s timeline, they could omit a task, 
or they could request that something in the timeline be delayed. This lack of control over one’s own schedule has 
had negative consequences (Ref. 1). There is anecdotal consensus among astronauts that control over their own 
schedules will mitigate the stresses of long-duration missions. On ISS, a modicum of crew control is provided by the 
“job jar.” Ground controllers prepare a task list (a.k.a. “job jar”) of non-conflicting tasks from which jobs can be 
chosen by the in-space crew. Because there is little free time and few interesting non-conflicting activities, the task- 
list approach provides little relief from the tedium of being micro-managed by the timeline. 

Scheduling for space missions is a complex and laborious undertaking which usually requires a large cadre of 
trained specialists and suites of complex software tools. It is a giant leap from today’s ground-prepared timeline 
(with a job jar) to full crew control of the timeline. However, technological advances, currently in- work or proposed, 
make it reasonable to consider scheduling a collaborative effort by the ground-based teams and the in-space crew. 
Collaboration would allow the crew to make minor adjustments, add tasks according to their preferences, understand 
the reasons for the placement of tasks on the timeline, and provide them a sense of control. In foreseeable but 
extraordinary situations, such as a quick response to anomalies and extended or unexpected loss of signal, the crew 
should have the autonomous ability to make appropriate modifications to the timeline, extend the timeline, or even 
start over with a new timeline. 

The Vision for Space Exploration (VSE), currently being pursued by the National Aeronautics and Space 
Administration (NASA), will send humans to Mars in a few decades. Stresses on the human mind will be 
exacerbated by the longer durations and greater distances, and it will be imperative to implement stress-reducing 
innovations such as giving the crew control of their daily activities. 

A. Major Consideration 

Implementation of crew collaboration will be driven by one major circumstance - the round-trip light-time delay 
between Earth and Mars can be up to 44 minutes and will never be less than 6 minutes (Fig. 1). Every 26 months. 
Mars cycles between close approach and far retreat. Barring some breakthrough in propulsion technologies, a 
mission to Mars will take longer than two years during which the light-time delays will average over 20 minutes. 
Normal voice conversations will be impossible. Instant transfer of information as provided by today’s Earth-based 
internet will also be negated. The communication delays will change the way human missions are operated. The 
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crew will be the first responders to emergencies and mundane anomalies; they will attend autonomously to all 
alarms, switching the troublesome system to a safe mode and/or making quick repairs and reconfigurations. What 
we now think of as ground 
control teams will become 
ground support teams. 

The inability to have 
normal conversations with 
the ground, seeing the Earth 
only as a point of light, 
having no immediate return- 
to-Earth options, interacting 
only with their companions, 
having limited food choices, 
drinking recycled water, and 
doing the same maintenance tasks each day will make life stressful for the crew. Crew collaboration on the 
development of the daily timeline for themselves and for the systems they use and maintain will provide them 
necessary knowledge to execute the timeline and necessary influence so that they will feel that they are in control of 
their own destiny. 

B. Collaboration 

Collaboration is working jointly to produce a product or to attain a goal. Usually collaborators share ideas, 
compromise on goals or methods, contribute where their expertise allows, and jointly arrive at an objective. There 
are two types of collaboration, interactive and passive. Interactive implies .that the collaborators communicate during 
the collaboration process. Passive collaboration happens without direct communication. An instance of interactive is 
a group of authors who brainstorm the contents of a paper. An instance of passive collaboration is the progression of 
teachers who instruct children from early childhood into adults; another instance is the corps of guards who attend 
all the gates at an arena so that only ticket holders are allowed to enter. 

While passive collaboration is based on a concept of operations rather than communication, there are several 
methods which support interactive collaboration; often, these are used in combinations. The more common methods 
are listed below in approximate order of productivity. 

• Face-to-face - collaborators talk to one another across the table, use whiteboards, share notes, etc. 

® Teleconferencing and web conferencing - collaborators simulate being face-to-face using voice, possibly 
video, and sometimes an electronic white board or a shared computer “desktop.” 

• Custom software - an application designed to support collaboration on a specific task or product. Internet 
games are a common example of custom software. 

• Instant messaging and chat rooms ~ collaborators type messages which are displayed almost instantly for 
each collaborator. 

• File transfer - collaborators post and retrieve files using peer-to-peer transfer or a common drop box. 
Commercial products are available to automate this method. 

• Electronic forums - collaborators post messages on a message board. 

• Electronic mail - collaborators correspond by sending messages over the internet. 

• Postal mail - collaborators correspond by written mail. 

For Earth-based support teams and humans on a mission to Mars, several of these collaboration methods will not 
be available and others (file transfer, electronic forums, and electronic mail) will be degraded. Custom software and 
the concept of operations can be tailored to deal with the time delays. Collaboration between the in-space crew and 
the ground support will, no doubt, use all the tools available including a delay-tolerant communication 
infrastructure, delay-tolerant scheduling software, and a specially tailored concept of operations. 

C. Integration 

In any large community of collaborators, terminology and interfaces are important. The VSE will be the first 
time that intelligent robots and rovers have been on the same mission as humans. A “master” timeline will be needed 
that integrates the timelines of the crew, automatic systems and intelligent systems. Any member of the community 
of contributors may need to view or change any timeline - for example, the crew may need or want to schedule the 
activities of the rovers. The scheduling requirements for all systems, including the crew, must be described using the 
same terminology; likewise for the resulting timelines. The user interfaces to the software must be similar for all 
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collaborators - the timeline for a crewmember and the timeline for an automatic system must be viewable on the 
same display. Additionally, the interface must have special instances for use by the crew in the cabin of the habitat 
or in their spacesuit while walking on the surface of Mars. 

BL Concept of Operations 

Human missions to the Moon and Mars will use extraordinarily complex hardware and software systems and 
will include significant technological and scientific investigations. The missions will extend for years, and ground 
support will require collaboration from many widely dispersed contributors. The cost to collect the ground-based 
planning and scheduling collaborators in a central location will be prohibitive. The only affordable solution will be 
to distribute the planning and scheduling efforts. It logically follows that if the planning and scheduling effort is to 
be distributed, it can be distributed to the crew on the Moon, in transit to Mars and at Mars. Distributed planning and 
scheduling has been used to a small extent for ISS. Research into concepts of operations (Ref. 2) which maximize 
the distribution and the cost savings has yielded viable results.* To be successfully accepted and implemented, a 
distributed concept of operations must be considered and developed beginning as early as possible. The concept 
proposed here is intended to be a starting point for the concept which will eventually be used to allow full 
distribution of the planning and scheduling function to all collaborators including the in-space crew. The concept has 
the additional advantage of giving the crew full autonomy if they should need it. Figure 2 shows the contributions to 
the planning and scheduling effort by different collaborators during the preparation of the preliminary timeline on 
Earth and after the timeline is uplinked to the crew. Text messages, notes, email, and voice memos are not shown on 



Figure 2. Concept of Operations 

the chart. The development of the timeline is divided into two phases, preliminary and final. Preliminary timelines 
are developed on the ground using a ground-based instance of the scheduling system. Before the beginning of each 
work day, the timeline is transferred to an in-space instance of the scheduling system. In-space crewmembers have 
time-delayed access to the ground instance and the ground support has time-delayed access to the in-space instance. 


f Fully distributed concepts of operations will not be implemented for ISS because the paradigm shift would require 
rewriting current international agreements, incur appreciable one-time costs including new software, procedures, and 
training, and the phase over would extend almost to the end of the ISS mission. 
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A. Widespread Collaboration on Preliminary Timeline 

Collaboration is cost effective because those with the best knowledge are able to contribute that knowledge 
directly. For the same reason, collaboration produces the best product. Collaboration on the planning and scheduling 
effort for the preliminary timeline is described by listing what each collaborator contributes. 

• Task Experts - Task experts include hardware developers, scientists, engineering support teams, doctors, 
astrobiologists and others who have first-hand knowledge about the tasks to be done to maintain the 
vehicle/habitats and to conduct the science activities. These experts define the tasks and arrange them into 
the required sequences in order to accomplish the goals. The task definitions include the procedure 
descriptions, the equipment (and operation modes) to be used, the conditions required, and the durations. 
These task models do not directly define the resource amounts required by the tasks; resources are defined 
by the equipment mode models entered by the hardware and systems experts. The sequence definitions 
include the temporal relationships between the tasks, relationships to other sequences, windows of 
opportunity and other data. The information is entered into a central data repository used by the scheduling 
system. 

• Hardware and System Experts - Hardware and systems experts have detailed knowledge about how the 
hardware is integrated into the vehicle and how that hardware can be used. They also have knowledge 
about the software systems and how they behave. The experts enter the equipment mode models into the 
central data repository. For each mode of each piece of equipment, these models define how much of each 
resource is used. For example, an oven for metallurgical analysis of regolith samples has several operation 
modes using different resources (power, inert gases, data rates, etc.) and amounts. The hardware and 
systems experts know how the oven functions and how it is connected to the systems (which power bus, 
which controller, which video bus, etc.). These equipment mode models are used by the task experts when 
defining the tasks; therefore, these models eliminate the need for task experts to be hardware experts. 

• Scheduling Cadre - The scheduling cadre interacts with program managers, engineering support teams, 
and the science teams to determine the day-by-day plans. Based on the plan, the cadre submits task 
sequences to the scheduling engine which adds them to the timeline. The scheduling engine accepts 
remote requests into a queue of sequences to be scheduled. The engine combines the task models with the 
equipment mode models to create a complete model including all timing, resources, relationships and 
conditions, and it then schedules the request. The scheduling cadre can use a timeline editor (mixed- 
initiative scheduling) to make final tweaks to the timeline. The modeling and scheduling engine are 
powerful enough that mixed-initiative scheduling will be required only in rare circumstances. 

• Crew — Crewmembers can send messages, receive messages, and read the minutes of the various planning 
group meetings. The crew has first-hand knowledge of the in-space situation. The crew can collaborate on 
the development of the preliminary timeline because they can view the task models, the equipment mode 
models, the developing (partial) timeline and the crew can submit scheduling requests to the instance of 
the scheduling engine currently being used by the ground support teams. 

• Other Contributors - Using appropriate software, other contributors provide availability predictions for 
resources (such as power), conditions (such as daylight or communications), and companion autonomous 
systems (such as rovers or robots). 

In addition to developing the preliminary timeline, the collaborators also develop a task list containing sequences 
which are candidates for adding to the timeline. These may be purely discretionary or they may be sequences that 
are planned for the near future. 

B. Collaboration on Final Timeline 

The final timeline is developed in space. On the day or evening before execution, the preliminary timeline and 
all supporting data are transferred to an instance of the scheduling system which is co-located with the crew. 
Crewmembers have immediate and full access to all features of the system and they are the main contributors to the 
finalization of the timeline. They have first-hand knowledge of the in-space systems; they know their own 
preferences and needs. They can remove omitted tasks from the timeline so that unused resources are known by the 
system to be available. They can modify the equipment mode models to reflect actual in-situ configurations, and 
they can modify task and sequence models to reflect personal experience. They can add to the timeline by selecting 
items from the proposed task list and submitting them to the scheduling engine so that the tasks are assigned times 
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and so that the resource usage is tracked*. The modification to the timeline includes not only tasks done by the crew 
but also un-attended tasks done by automated or autonomous systems such as robots. In rare circumstances the crew 
could use mixed-initiative scheduling to modify the timeline; however, mixed-initiative scheduling can consume a 
lot of valuable crew time. 

Ground support teams collaborate on the final adjustments to the timeline by reviewing modifications to the 
models or by updating the models (updating the Earth-based instance and uplinking it). They collaborate on timeline 
additions by reviewing the crew’s modifications and commenting via text messaging. The ground teams can also use 
remote access to submit new requests to the in-space scheduling engine. 

C. Crew Autonomy 

When a situation arises in space that necessitates modification and execution of the timeline before the ground 
can see the change (due to light-time delays), the crew can go ahead and make the change. It is essential for the crew 
and the in-space vehicle or habitat to be able to function if there is an extended communication loss. The crew may 
need to extend the timeline for a few hours or for many days. The installation of a complete planning and scheduling 
system in space will provide the needed capability. 

HI. Collaborative Scheduling Software 

Enabling widespread and crew-to-Earth collaboration on daily timelines as described in the preceding concept of 
operations requires major, but evolutionary, changes in scheduling software. In addition, a robust communication 
infrastructure designed for long round-trip communication delays is needed. Current development efforts are 
underway on delay-tolerant networking, intemet-in-space, and publish/subscribe methods. The appendix describes 
interplanetary networks and the message bus architectures. Other communication infrastructure elements are 
planned. Relay satellites will orbit Mars to provide communication for the twelve hours per Earth day during which 
the habitat will be on the far side. Additionally, a relay satellite in orbit around the sun will provide communication 
when the sun is directly between Earth and Mars (in worst cases, the sun-occultation communication blockage could 
be two weeks long). 

The salient features of a scheduling system which can support the collaboration-based concept of operations are 
use of standard terminology, a comprehensive modeling schema that represents all the constraints, an automatic 
scheduler that understands the models and produces a desired timeline, remote access to the scheduling system, a 
human interface that is user friendly to all users including the crew, and the ability to perform over a delay-tolerant 
network. Figure 3 shows the components of such a scheduling system and how they are used by the collaborators. 
There would be two instances of the scheduling system, one on Earth and another in space. The Earth-based instance 
supports widespread collaboration on the preliminary timeline - the ground support teams being the primary 
contributors and the crew offering limited contributions. The in-space instance supports collaboration on the final 
timeline with the crew being the primary contributors and the ground support offering limited contributions. 

The crew will have little time to work on development of the timeline. Most equipment mode models and task 
models will be pre-constructed before transferring them to the in-space software. Most of the timeline will be 
developed on Earth. After the locus of development moves to space, the ground can review timeline additions and 
changes made by the crew when made far enough in advance of execution; but the crew does not have time to 
“discuss” the changes via text messages. Some crew changes to the timeline will be in response to the ongoing 
situation and cannot wait for the light-time delay for review and oversight (these changes can be called real-time 
replanning). The modeling schema and the scheduling engine must automatically produce valid timelines. 

A. Equipment Mode Modeling 

In space, as on Earth, most tasks are accomplished using equipment. Most types of equipment have modes of 
operation; e.g., a microwave oven has defrost, reheat, and cook. The microwave oven’s power requirement for each 
mode is predefined. On a space platform, the characteristics of each piece of equipment are well-known to those 
building and integrating the equipment into the platform systems. The equipment and their modes may be modeled 
independently of the tasks that will use the equipment. Equipment mode models may use multiple resources and 


* On the ISS, task-list items are not submitted to the scheduling engine; the crew selects them and executes them 
whenever they want (the crew notifies the ground of their actions). For this reason, task list items are limited to 
those that do not have difficult timing requirements, do not use scarce shared resources, and they are limited to tasks 
that are done by the crew. Additionally, the ISS crew cannot see the scheduling models of the tasks, only the 
procedures. 
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may use other equipment in specified modes. Equipment mode models can describe a hierarchy of constraints and 
alternate resources. Equipment mode models allow low-level resources such as power to be hidden from the task 
modeler. The task modeler can only request these low-level resources by selecting equipment that uses them. Using 
equipment modes to model resource usage is an extension of a method previously proposed in Ref. 3. 



Figure 3. Software and Infrastructure 


Earth-based collaborators will build these models using a distributed-via-remote-access § feature of the 
scheduling system to build models in a central data repository. Using a record locking or record checkout method 
allows multiple users to work at the same time as long as they work on different equipment mode models; revision 
control is built into the system. All collaborators can view the data of other collaborators. 

The in-space crew can view the models in the Earth-based repository via the delay-tolerant network. After the 
data is transferred to the in-space instance, the crew, using their knowledge of the local configurations, can make 
needed modifications to the models. The model viewing and editing software must be usable by the crew. The 
Earth-based support teams can review the crew’s changes to the models by either remote display or by transferring a 
copy of the datasets back to Earth. 

B. Task Modeling 

A specification of the types of goals, states, activities, equipment (resources) and constraints necessary to 
achieve an objective is called a task model. Task models can range from simple to complex and can depend heavily 
on the capabilities of the scheduling system that will use them. For the most part. Earth-based task experts will 
construct, review, and test the models before flight. The modeling schema needs to represent all the requirements so 
that automatic scheduling can be employed; it also needs have a straightforward representation so that the task 
experts (technicians, scientists, etc.) can easily enter the models; and it needs to be easy to use so that all 
collaborators, including the crew, can understand the models. A possible modeling schema has been previously 
proposed (Ref, 4); some of the key features are: 


§ The function is distributed to remote collaborators by providing remote access to the central location. Accessing 
the central location could include automatic download and/or update of a local client. In-space software would not 
be automatically updated. 
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• Decomposition of the operations into salient components — Operations are decomposed into tasks that 
define resource requirements and sequences that define relationships between tasks. Sequences can also 
contain other sequences, repeated tasks and sequences, and optional tasks and sequences. 

• Rich expression of the relationships between components - Common-sense representations of temporal 
relationships use everyday concepts like follows, during, and overlap. Innovative enhancements to 
represent die continuance of resource usage between tasks, the interruption of tasks, minimal percent 
coverage, and temporal relationships to outside tasks have been added to the modeling schema. 

® Public services - The modeling schema also includes the concept of public services - models that are 
scheduled at the request of another model. 

® Flexibility and nuances - Variable timing, alternate resources and sequences, optional items, and other 
nuances are modeled. 

The collaborators use the same type distributed- via-remote-access features as the equipment mode model 
builders to access a central data repository. Normally, all collaborators can view the data of other collaborators; 
however, models containing sensitive information may be hidden to some collaborators, but never to the crew. The 
builders of task models can submit their models to the scheduling engine to test the models for validity and usability. 
Depending on the concept of operations, the results of scheduling can be part of the developing timeline or they can 
be tested only. 

Like equipment mode models, the in-space crew can also view the task models via the delay-tolerant network. 
After the data is transferred to the in-space instance, the crewmembers, based on their local knowledge or personal 
preferences, can modify the task models. Complex syntactical languages, difficult-to-navigate user interfaces, or a 
modeling schema that does not match the real world could render such a system nearly useless to the crew. The 
Earth-based support teams can review the crew’s changes to the models by either remote display or by transferring a 
copy of the datasets back to Earth. 

C. Automatic Scheduling 

Automatic scheduling will be the primary mode of 
developing the task timelines. An incremental scheduling 
engine has characteristics which enable supporting multiple 
collaborators simultaneously contributing to the 
development of one timeline. An incremental engine is fed 
by a queue of scheduling requests (sequences of tasks). The 
engine adds each scheduling request to the timeline without 
adjusting the times of already-scheduled tasks and without 
introducing constraint violations or resource overbooking. 

The core logic of an incremental engine is usually an 
implementation of a greedy algorithm (Ref. 5); that is, it 
makes choices based only on scheduling the current request. 

These engines may use analytical, heuristic, algorithmic and/or artificial intelligence techniques. Incremental 
scheduling engine usage is depicted in Fig. 4. Some scheduling requests are emphasized to show that they may be 
very complex. The figure also shows that multiple queues from multiple remote users may be merged into a single 
queue. 

As an incremental scheduling engine processes a sequence, it will search for a near-optimum placement for the 
multiple tasks of the sequence being scheduled**. The tasks always have temporal relationships to each other and 
may share the same resources. However, all tasks scheduled by previous scheduling requests are locked, and the 
residual resource profiles are treated as initial resource profiles for the current request. 

Collaborators use remote access to submit scheduling requests from the repository of task models. Multiple 
collaborators can submit to the queue simultaneously. The scheduling system provides the ability for all users to see 
the current timeline as it is being developed. The crew can used tire delay-tolerant network to submit scheduling 
requests and to view the timeline. 

Incremental scheduling engines and their usage is discussed in detail in Ref. 6. 

D. Mixed-Initiative Scheduling 

Mixed-initiative scheduling refers to building a timeline using a timeline editor; i.e., it is a manual process. 
Mixed initiative is used when the contributor knows requirements that are not described in the scheduling requests. 


Incremental engines do not provide global schedule optimization. 



Figure 4. Incremental Engine Usage 
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the scheduling engine is weak, only a few new requests are to be added to the timeline, or the user wants to fully 
control the results (Fig. 5). Some timeline editors allow the user to move already-scheduled tasks; however, this 
requires the user to have global knowledge of the scheduling requirements 1 ^. Mixed-initiative scheduling is also 
discussed in Ref. 6. 

Mixed-initiative schedulers usually have logic to help the user avoid violating constraints and allow the user to 
override constraint limits. If the models are complete, the editor might invoke iterative-repair logic to move other 
tasks and eliminate constraint violation introduced by a 
manual edit. The editor might invoke an incremental 
scheduler to make slight adjustments to the user’s input; 
this feature is called “snap-to.” Additionally, the editor 
might use an incremental engine to suggest times where 
tasks could be placed without introducing constraint 
violations. 

The timeline editor will display considerable 
information about the timeline, the models, and the 
availabilities. It will be closely coupled to the data 
repository and the scheduling engine. It will not operate 
over the delay-tolerant network and will be only available 
to local users. During the development of the preliminary 
timeline, a cadre of highly skilled users, called the 
“scheduling cadre,” will be the primary users. After the locus of development moves to space, the crew can use 
mixed-initiative scheduling, but will do so rarely. 

E. Resources, Conditions, and Autonomous Systems 

Scheduling depends on the availabilities of resources which are scarce and shared, on conditions which occur 
intermittently, and on the available of other, possibly autonomous, systems. Power, cameras, and storage space are 
examples of resources; daylight, communication links, and sand storms are examples of conditions; and self- 
scheduling robots and rovers are examples of autonomous systems. During the development of the preliminary 
timeline, availabilities are predicted by Earth-based software and autonomous systems are simulated. During the 
finalization of the timeline in space, the availabilities of resources and future conditions are predicted by adjunct 
software. For example, on Mars a weather prediction program will warn of approaching sand storms. 

The in-space scheduling systems will negotiate with the rovers and robots to jointly arrive at a common timeline. 
The negotiation might go like this: 

• The main scheduling system will ask a robot if it is available to do a certain task at a certain time. 

• The robot scheduler will attempt to the schedule the requested task; if possible, give an affirmative 
answer; if not, an alternate time might be suggested. 

• After the main scheduler has found acceptable times for all tasks of the scheduling request, it would send 
the robot a commit message and the robot would complete its scheduling. 

F. Terminology and Standards 

Historically, the planning and scheduling for space domain has been fragmented along human vs. non-human 
flights and also by the sponsor of the missions (NASA center, ESA, etc.). The fragments have each evolved their 
own terminology and standards for expressing planning and scheduling requirements, results and displays. Many of 
the differences are semantic - a consumable resource and a depletable resource have the same characteristics, a state 
is a condition, etc. Some of the differences are substantive - activities have durations and are delimited by start and 
stop events. In one scheme, temporal relationships may be expressed relative to the activity; in another scheme, they 
are relative to the delimiting events. “Activity A occurs during activity B” can be directly expressed in one scheme 
but in the other becomes “start of B occurs on or after start of A and stop of B occurs before or on stop of A.” Goals 
may be chains of events or sequences of activities. Similar differences exist for the results and the displays. Human 
missions to the Moon and Mars will bring together contributors from many backgrounds because the missions will 
include humans, robots, rovers, automatic systems and remote-commanded systems. 



Figure 5. Mixed-Initiative Scheduling 


ft Mixed-initiative scheduling does not automatically provide global schedule optimization. However if the user is 
an expert and the problem is straight-forward, global optimization might be achieved. 
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Collaboration by a large diverse group of ground support persons and by the crew will require a standard 
terminology be adopted by all. It is especially important that the crew, at a minimum, be able to look at any timeline 
(for any system), understand it, comment on it; and, in some cases, modify it. The crew is dedicated to planning and 
scheduling and should not devote time and effort to learning different scheduling terminologies or methods. 
Fortunately, existing standards bodies, such as the Consultative Committee for Space Data Systems (CCSDS) (Ref. 
7), are available to apply their expertise in establishing, negotiating, and documenting the needed data standards. 






G. User Interfaces 

Good user interfaces with the planning and scheduling software are necessary for successful collaboration 
between diverse contributors. The user interface needs to allow those who are not experts in planning and 
scheduling to perform as “virtual” experts. Like the driver of a car who is able to steer the car without concern for 
how to manipulate the steering wheel, the user of the planning and scheduling software should be able to produce 
the desired timeline without concern about the user interface. 

To support widespread collaboration and remote access across the solar system, the scheduling software user 
interfaces will need some special features. One might say 


the software must have delay-tolerant user interfaces. 

Delays will be caused by light-time and by loss of signal 
to relay satellites. Some of the ameliorating features of 
the software are: 

• Maximizing local processing to avoid delays. 

• Continuing to interact while waiting for a reply 
to a message. 

• Providing visibility into the stack of sent 
messages showing time remaining until a 
response is expected. 

The crew will have special user interface needs. The 
console in the habitat or vehicle may have the standard 
user interfaces, but the interfaces used when outside will have special requirements. Figure 6 shows a PDA-like 
device attached to a crewmember’s sleeve. This device is in communication with the planning and scheduling 
system in the habitat. The crewmember should be able to look at the timeline and possibly modify the timeline using 
the sleeve-attached device. 



Planning and scheduling 
system interface 


Figure 6. A Special User Interface Situation 


IV. Conclusion 

As humans explore regions of space where the Earth appears as a mere point of light, and round-trip 
communication delays exceed half an hour, it will be imperative that the humans on the journey exercise significant 
control over their daily timeline and the timelines of their companion systems. Yet the crew does not have the time 
to do all the scheduling. Scheduling will be a collaborative effort between multiple ground support teams and the 
crew. 

A new concept of operations calls for developing the preliminary timeline on Earth, having the Earth-based 
teams as the primary contributors and the crew providing only minimal input. Once the preliminary timeline is 
uplinked to the in-space location, the crew will become the primary contributors and the Earth-based teams will 
provide only minimal input. This concept is tailored to function effectively in the delayed communication 
environment. 

Planning and scheduling software will evolve to meet the needs of the new concept of operations. Automatic 
scheduling will become the normal way to produce the timeline. Modeling will be partitioned into equipment mode 
modeling and task modeling so that different experts with different knowledge can contribute effectively. An 
equipment mode model will reflect the different modes in which the equipment operates and will book all resource 
and condition requirements. Task models will be grouped into sequences showing the temporal relationships of the 
tasks. An incremental approach to scheduling will enable multiple experts to schedule sequences without impacting 
sequences scheduled by other experts (the crew being among these experts). Because the models reflect all the 
requirements and the scheduling engine can produce good timelines, mixed-initiative scheduling will be used rarely. 

The synergy of the new concept of operations, delay-tolerant communication and software (including user 
interfaces), and advances in scheduling technology will allow the in-space crew and Earth-based support teams to 
collaborate on the scheduling of the tasks done by the crew, the operation of the vehicle or habitat, and the operation 
of the various near-autonomous robots and rovers. 
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Appendix 

Planning and scheduling is only one application that will depend heavily on a communications framework that 
will carry data between Earth and Mars or in between. Without such a framework, in-space collaborative scheduling 
would be impossible. The cost of spaceflight being prohibitive as it is, much work will be done to leverage existing 
technologies and commercial hardware and software to use them and manipulate them to work in these foreign 
environments. Accomplishing this will necessitate standardizing communication between applications using 
concepts like a message bus which travels over ubiquitous protocols such as the internet modified for light-time 
delay. 

A. Inter-Planetary Internet 

Standardized digital communication devices have revolutionized the way we communicate and interact with 
information. But the foundation of the technology, TCP/IP, does not translate well in a space environment where 
line-of-sight connectivity is intermittent, communications 

have delays and data may have high error rates requiring Dela y.' Tolerant Segment 

retransmissions. However, the technology of TCP/IP can Earth|ntemet Relay Re | ay Relay Mars Internet 
easily be leveraged to create Mars-based internet that 
connects remotely to today’s Earth-based internet. The 
interoperability between the networks is where new 
technology is needed. Based on on-going research, a new 
concept, Delay-Tolerant Network (DTN), is evolving to Store-and-forward 

mitigate the delay problem. DTN could employ concepts 

such as store-and-forward message delivery. In store-and- Figure 6. Inter-Planetary Internet 
forward, relay systems capture incoming data and store it 

locally before transmitting it to the next link in a chain (Fig. 6). If there is a transfer failure, the data will not have to 
travel the complete distance again. DTNs can be used to route data between two traditional TCP/IP networks almost 
transparently to the TCP/IP packets concept. However, many of today’s applications are not designed with such 
communication delays in mind. Loss of continual heartbeats or continuous data streams would cause many of 
today’s applications to fail as they wait for the next packet to arrive. Therefore, any applications themselves must be 
built with data delays in mind. The applications must be more robust and fault tolerant and should not malfunction 
when there is a long data delay. 

B. Message Bus 

Message buses standardize information exchange as well as data pathways between two end points. Buses can be 
layered upon DTNs to provide more abstraction between the software and the communication infrastructure, 
allowing for the flexibility of architecture upgrades. Most message bus modes include a publish/subscribe protocol, 
sometimes called “pub/sub,” in addition to more direct request/reply connections. 

In the publish/subscribe mode, client applications subscribe to information they would like to be provided. As 
messages pass by, messages that match the requested type are captured by the client API and passed to the 
application. 
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